부록 — 바로 쓰는 99가지 팁 (입문판)

원서: 클로드 코드 완벽 가이드 (코드팩토리 최지호)

이 부록은 클로드 코드를 더 빠르고 똑똑하게 쓰는 99가지 작은 습관 모음이야. 한 번에 다 외울 필요 없어. "아, 이런 게 있구나" 하고 한 번 훑은 뒤, 필요할 때 다시 펴 보면 돼.

각 묶음마다 일상 비유부터 던지고, 그다음 짧은 터미널 예시로 연결할게. 명령어가 낯설어도 괜찮아. 비유를 먼저 머리에 넣으면 명령은 그냥 따라온다.

한 가지 미리 약속. 이 부록에는 요금제, 모델 이름, 도구 버전 같은 시간이 지나면 바뀌는 값이 자주 나와. 그런 숫자는 모두 "원서/노트 기준 예시"일 뿐이야. 진짜 최신 값은 항상 공식 문서에서 확인하자.

0. 먼저 알아둘 말들 (용어 미리보기)

본문에 자주 나올 말 몇 개만 한 줄로 풀어둘게. 처음엔 이 정도만 알면 충분해.

용어 한 문장 뜻 일상 비유
모드 클로드 코드가 일하는 방식(매번 물어볼지, 알아서 할지) 자동차 기어
서브에이전트 메인이 일부 작업을 떼어 맡기는 보조 일꾼 보조 요리사
CLAUDE.md 프로젝트마다 두는 작업 지침서 파일 알바생 업무 매뉴얼
슬래시 커맨드 /로 시작하는 내장 명령(예: /init) 앱의 단축 버튼
콘텍스트 클로드가 지금 기억하고 있는 정보 범위 책상 위에 펼친 서류
토큰 클로드가 글을 읽고 쓸 때 세는 글자 단위 통신 요금의 데이터양
MCP 외부 서비스를 클로드 코드에 꽂는 표준 규격 스마트폰 앱 설치

이제 시작하자.

1. 실행 방식 (팁 01~03)

이 장에서 딱 3가지만. 1) 모드를 바꾸면 일하는 방식이 바뀐다 2) 복잡한 일은 먼저 계획부터(플래닝 모드) 3) 안전한 반복 일은 다 맡겨도 된다(YOLO 모드)

학습 목표 이 장을 마치면 모드 4가지를 구분한다. Shift+Tab으로 모드를 바꾸는 법을 따라 한다. 플래닝 모드와 YOLO 모드를 언제 쓰는지 설명한다.

막힌 적 있죠? 그게 모드야

클로드 코드한테 "회원가입 만들어줘" 했더니 파일 하나 건드릴 때마다 "이거 해도 돼요?" 하고 계속 물어봐서 답답했던 적 있지? 반대로 "그냥 알아서 해" 했다가 엉뚱한 파일까지 손대서 놀란 적도 있고.

이 "얼마나 물어볼지"를 정하는 게 바로 모드야. 모드는 자동차 기어라고 생각하면 쉬워.

비유 (자동차) 클로드 코드에서 주의
수동 운전 (매번 내가) 일반 모드 — 작업마다 확인 느리지만 가장 안전
크루즈 컨트롤 자동 승인 — 안전한 명령만 자동 익숙한 일에만
자율주행 YOLO 모드 — 전부 자동 안전한 일에만, 위험 큼
내비게이션 플래닝 모드 — 경로(계획) 먼저 복잡한 신규 작업에 좋음

따라 하기

# 팁 01: Shift+Tab 한 번 누를 때마다 모드가 순환해서 바뀐다
# 일반 -> 자동 승인 -> 플래닝 -> 다시 일반

# 팁 02: 복잡한 일은 플래닝 모드부터
# 잘못된 예 (바로 코드부터)
claude "회원가입 기능 만들어줘"

# 올바른 예 (계획 먼저)
# Shift+Tab 으로 플래닝 모드로 바꾼 뒤
claude "회원가입 기능을 만들 건데, 먼저 계획을 세워줘"

# 팁 03: YOLO 모드는 안전한 반복 일에만
# 테스트 코드 작성, 줄맞춤(린트) 정리 같은 일

이럴 때 이렇게 처음 보는 큰 기능을 만들 땐 → 플래닝 모드로 계획부터 보고 출발. 이미 100번 해본 단순 정리 작업이라 → YOLO 모드로 한 번에.

한 걸음 더 ▸ YOLO 모드 이름의 뜻

YOLO는 "한 번뿐인 인생"이라는 뜻의 유행어에서 왔어. "확인 안 받고 다 질러본다"는 느낌이라 이 이름이 붙었어. 편하지만 위험하니, 처음엔 일반 모드로 충분히 익숙해진 뒤에 써.

다음 장 예고: 클로드 코드한테 직접 "뭐 할 수 있어?" 물어보는 법. 지금 몰라도 됨.

2. 사용법과 도움말 (팁 04~08)

이 장에서 딱 3가지만. 1) 모르면 클로드 코드한테 직접 물어봐라 2) /release로 새 기능을 챙겨라 3) 서비스가 이상하면 상태 페이지를 봐라

학습 목표 이 장을 마치면 기능을 직접 물어보는 법을 따라 한다. 릴리즈 노트 확인법을 설명한다. 서비스 상태를 어디서 보는지 구분한다.

설명서를 다 읽어야 하나? 아니, 그냥 물어봐

새 앱을 받으면 설명서를 처음부터 읽는 사람은 드물어. 보통은 "이거 이것도 돼?" 하고 그냥 눌러보지. 클로드 코드도 똑같아. 기능이 궁금하면 사람한테 묻듯이 그냥 물어보면 돼.

비유 클로드 코드에서 주의
시리한테 "뭐 할 수 있어?" 클로드한테 "PR 만들 수 있어?" 답을 맹신 말고 한 번 시험
앱 업데이트 알림 /release로 새 기능 확인 가끔 들여다보기
서비스 점검 공지 Anthropic 상태 페이지 내 코드 탓 전에 먼저 확인

따라 하기

# 팁 04: 기능이 궁금하면 직접 물어보기
"풀 리퀘스트 만들 수 있어?"
"데이터베이스 연동 가능해?"

# 팁 05: 프로젝트 분석 요청
"이 프로젝트의 전체 구조를 설명해줘"
"src/auth 폴더가 하는 역할을 알려줘"

# 팁 06: 외부 서비스 연동법 질문
"Stripe API 연동하는 방법 알려줘"

# 팁 07: 릴리즈 노트 확인
/release

# 팁 08: 서비스 상태 확인
# status.anthropic.com 에서 장애 여부 확인 (알림 구독도 가능)

이럴 때 이렇게 "클로드 코드가 갑자기 느려졌다" 싶으면 → 내 코드부터 의심하지 말고 상태 페이지 먼저. "이 기능 되나?" 싶으면 → 검색하지 말고 클로드한테 바로 질문.

한 걸음 더 ▸ 릴리즈 노트가 왜 중요해

클로드 코드는 자주 업데이트돼서 새 기능이 계속 생겨. /release를 가끔 보면 "어, 이런 게 생겼네" 하고 놓친 기능을 줍게 돼. 단, 노트에 적힌 버전이나 수치는 그 시점 기준이야. 최신은 공식 문서 확인.

다음 장 예고: 일꾼을 여러 명 두고 동시에 시키는 법. 지금 몰라도 됨.

3. 서브에이전트 (팁 09~13)

이 장에서 딱 3가지만. 1) 터미널 여러 개로 동시에 일할 수 있다 2) 보조 일꾼(서브에이전트)에게 일부 작업을 맡길 수 있다 3) Parallel로 동시에 여러 개를 처리한다

학습 목표 이 장을 마치면 서브에이전트가 무엇인지 설명한다. 멀티에이전트와 병렬 실행을 구분한다. Parallel 키워드 사용법을 따라 한다.

혼자 다 하니 느렸죠? 그게 서브에이전트가 필요한 순간

요리사 한 명이 샐러드 만들고, 국 끓이고, 디저트까지 순서대로 하면 한참 걸려. 그래서 보조 요리사한테 "너는 샐러드만 담당" 하고 떼어주지. 클로드 코드의 보조 요리사가 바로 서브에이전트야. 메인이 큰 그림을 잡고, 잔일은 보조에게 맡기는 거지.

비유 클로드 코드에서 주의
보조 요리사에게 샐러드 맡김 서브에이전트에게 한 작업 위임 맡길 일을 또렷이 적기
주방에 요리사 여러 명 터미널 여러 개로 동시 실행 서로 같은 파일 건드리면 충돌
"다 같이 동시에" Parallel 키워드로 병렬 처리 정말 독립된 일에만

따라 하기

# 팁 09: 멀티에이전트 — 터미널 여러 개에서 클로드 코드 실행
# 터미널 1: 프론트엔드 작업
# 터미널 2: 백엔드 작업

# 팁 10: 서브에이전트에게 작업 위임
"인증 관련 파일들을 서브에이전트에게 분석시켜줘"

# 팁 11: 병렬 실행 (Parallel 키워드)
"Parallel로 서브에이전트를 사용해서 다음 3가지를 동시에 해줘:
1. 타입 오류 수정
2. 테스트 코드 작성
3. 문서 업데이트"

# 팁 12: 서브에이전트 커스터마이즈
# CLAUDE.md 에 서브에이전트가 지킬 규칙을 적어둔다

# 팁 13: 동시에 여러 시안 받기
"로그인 페이지 디자인을 3가지 스타일로 동시에 만들어줘"

이럴 때 이렇게 서로 상관없는 일 3개가 있다 → Parallel로 한 번에. 서로 같은 파일을 고치는 일이다 → 병렬 말고 하나씩 (충돌 방지).

한 걸음 더 ▸ 서브에이전트가 왜 효율적이야

서브에이전트는 자기만의 기억 공간(콘텍스트)을 따로 가져. 그래서 메인의 기억을 어지럽히지 않고 잔일을 처리할 수 있어. 디자인 시안 3개를 동시에 받는 것도 같은 원리야.

다음 장 예고: 클로드한테 줄 "작업 매뉴얼" 파일 이야기. 지금 몰라도 됨.

4. CLAUDE.md (팁 14~17)

이 장에서 딱 3가지만. 1) CLAUDE.md는 클로드한테 주는 업무 매뉴얼이다 2) 길어지면 요약하고, 부분별로 나눌 수 있다 3) #로 규칙을 즉석에서 추가한다

학습 목표 이 장을 마치면 CLAUDE.md가 무엇인지 설명한다. 하위 폴더 CLAUDE.md를 언제 쓰는지 구분한다. #로 메모리를 추가하는 법을 따라 한다.

매번 똑같은 설명 반복했죠? 그래서 매뉴얼을 둔다

새 알바생이 올 때마다 "우리 가게는 컵을 이렇게 정리하고…"를 매번 설명하면 지치지. 한 번 적어둔 업무 매뉴얼을 주면 끝이야. 클로드 코드한테 그 매뉴얼이 바로 CLAUDE.md 파일이야. "테스트는 꼭 이렇게 짜라" 같은 우리 프로젝트만의 규칙을 적어두는 곳이지.

비유 클로드 코드에서 주의
가게 업무 매뉴얼 프로젝트 루트의 CLAUDE.md 한 번 적으면 매번 적용
매뉴얼이 두꺼워짐 길어지면 요약 요청 핵심만 남기기
부서별 매뉴얼 하위 폴더에 CLAUDE.md 폴더별 규칙 분리
포스트잇 즉석 메모 #로 빠른 규칙 추가 즉석 등록 편리

따라 하기

# 팁 14: 주기적 업데이트
"CLAUDE.md를 현재 프로젝트 상태에 맞게 업데이트해줘"

# 팁 15: 요약 (너무 길어졌을 때)
"CLAUDE.md가 너무 길어졌으니 핵심만 남기고 요약해줘"

# 팁 16: 하위 폴더에 CLAUDE.md 생성
# src/auth/CLAUDE.md  -> 인증 관련 규칙
# src/api/CLAUDE.md   -> API 관련 규칙

# 팁 17: 빠르게 메모리 추가 (#)
# 프롬프트 맨 앞에 # 을 붙이면 그 내용이 CLAUDE.md 에 바로 들어간다
# 예: "#테스트는 반드시 Jest로 작성할 것"

이럴 때 이렇게 프로젝트 규칙이 자꾸 바뀐다 → 가끔 "업데이트해줘"로 매뉴얼 갱신. 방금 새 규칙이 떠올랐다 → #로 즉석 등록, 다음부턴 알아서 지킴.

한 걸음 더 ▸ 매뉴얼이 너무 길면 오히려 손해

매뉴얼이 너무 길면 클로드가 읽을 양이 늘어서 비효율이야. 그래서 가끔 "요약해줘"로 핵심만 남기는 게 좋아. 규칙이 부서별로 다르면 폴더마다 따로 두면 깔끔해.

다음 장 예고: /init, /model 같은 내장 단축키 모음. 지금 몰라도 됨.

5. 내장 기능과 명령어 (팁 18~27)

이 장에서 딱 3가지만. 1) Tab, /init, /model 같은 단축키를 알면 일이 빨라진다 2) -p 헤드리스 모드로 대화 없이 한 번에 실행한다 3) @파일, -r, -c로 파일과 이전 대화를 빠르게 부른다

학습 목표 이 장을 마치면 /init과 /model이 무엇인지 설명한다. 헤드리스 모드(-p)를 언제 쓰는지 구분한다. @파일로 파일을 참조하는 법을 따라 한다.

매번 손으로 다 쳤죠? 단축키 몇 개면 끝난다

스마트폰 단축키를 모르면 설정 앱을 매번 열어야 하지만, 알면 2초 만에 끝나잖아. 클로드 코드도 내장 명령 몇 개만 익히면 반복 입력이 확 줄어.

비유 클로드 코드에서 주의
자동완성 키 Tab — 경로 자동완성 오타 줄이기
새 폰 초기 설정 /init — 프로젝트 분석 후 CLAUDE.md 생성 새 프로젝트에서 한 번
요금제 확인 /model — 현재 모델 확인 비싼 모델 낭비 방지
무인 자판기 -p 헤드리스 — 대화 없이 한 번 실행 자동화 스크립트에
즐겨찾기 다시 열기 -r/-c — 이전 대화 이어가기 맥락 유지에 편리

따라 하기

# 팁 18: 경로 자동완성 — Tab 키
# "src/" 까지 치고 Tab -> 하위 폴더 자동완성

# 팁 19: 프로젝트 초기화
/init
# 프로젝트를 분석해서 알맞은 CLAUDE.md 를 자동 생성

# 팁 20: 모델 확인 (토큰 절약)
/model
# 잘못된 예: 간단한 일을 비싼 모델로 -> 토큰 낭비
# 올바른 예: /model 로 확인 후 가벼운 모델로 전환

# 팁 21: 프롬프트 즉시 실행
claude "issue-20 해결해줘"
# 시작과 동시에 바로 그 프롬프트 실행

# 팁 22: 헤드리스 모드 (-p)
claude -p "프로젝트 분석해줘"

# 팁 23: 데이터 주입 파이핑
cat test.md | claude -p "이 마크다운을 분석해줘"

# 팁 24: @로 파일 명시
"@src/auth/login.ts 파일의 버그를 찾아줘"

# 팁 25: Shift 드래그로 파일 참조
# Shift 누른 채 파일을 끌어다 놓기

# 팁 26: 기존 대화 재사용 (-r)
claude -r

# 팁 27: 직전 대화 재활용 (-c)
claude -c

여기서 잠깐, 새 말 한 줄. 파이핑은 한 명령의 출력을 다른 명령의 입력으로 이어주는 거야. 호스를 호스에 끼워 물을 흘려보내는 것과 같아. 위 팁 23이 cat의 출력을 claude로 흘려보내는 예야.

이럴 때 이렇게 간단한 작업인데 비싼 모델이면 → /model로 확인 후 가벼운 모델로. 파일 위치를 콕 집어 알려주고 싶다 → @경로/파일 로 명시.

한 걸음 더 ▸ -r 과 -c 차이

-c는 "바로 직전 대화"로 빠르게 들어가는 거고, -r은 "예전 대화 중 골라서" 이어가는 거야. 방금 하던 걸 잇는다면 -c, 며칠 전 걸 다시 연다면 -r이 편해.

한 걸음 더 ▸ 팁 21 vs 팁 22, 헷갈리지 말기

팁 21과 팁 22는 둘 다 "시작하자마자 일 시키기"라 비슷해 보이지만, 결정적 차이가 하나 있어. 바로 일 끝나고 대화창에 남느냐, 안 남느냐야.

식당에 비유해볼게.

비유 (식당) 클로드 코드에서 끝난 뒤
자리에 앉으며 첫 주문부터 외치기 팁 21: claude "issue-20 해결해줘" 대화창에 들어가 계속 주문 가능
포장 주문만 받고 바로 나가기 팁 22: claude -p "프로젝트 분석해줘" 대화 없이 답만 받고 끝

한 줄로 구분하면 이래. 팁 21은 대화창에 들어가되 첫 프롬프트를 바로 던지는 거야(대화는 계속 이어짐). 팁 22는 대화창 없이 -p로 한 번 실행하고 바로 끝나는 거야. 그래서 -p(팁 22)만 "헤드리스"라고 불러. (대화 화면 "머리"가 없다는 뜻이야.)

용어 한 줄: 대화창 없이 명령 한 번으로 끝내는 이 방식을 헤드리스 모드(Headless)라고 불러요. (대화 화면 없이 돌리는 것, 무인 자판기처럼 한 번 누르면 결과만 툭 나오는 방식.)

# 팁 21: 대화창으로 들어가되, 첫 프롬프트를 바로 던진다
claude "issue-20 해결해줘"
# -> 이 일이 끝나도 대화창에 남아서 다음 질문을 이어 할 수 있다

# 팁 22: 대화창 없이 -p 로 한 번만 실행하고 끝낸다
claude -p "프로젝트 분석해줘"
# -> 답만 받고 종료. 대화가 이어지지 않는다

이럴 때 이렇게 사람이 옆에서 계속 이어 대화하며 작업할 거다 → 팁 21(claude "..."). 스크립트·자동화에서 한 번 실행하고 결과만 받을 거다 → 팁 22(claude -p "...").

다음 장 예고: 그림과 스크린샷으로 의도를 전달하는 법. 지금 몰라도 됨.

6. 이미지와 시각자료 활용 (팁 28~31)

이 장에서 딱 3가지만. 1) 말보다 이미지가 빠르다 — 드래그로 붙여넣자 2) UI 문제는 스크린샷으로 콕 집자 3) 디자인은 ASCII 목업이나 Figma MCP로 옮기자

학습 목표 이 장을 마치면 이미지 주입법을 따라 한다. ASCII 목업이 무엇인지 설명한다. Figma MCP가 무엇을 하는지 구분한다.

"이런 느낌으로" 했더니 못 알아들었죠? 그럼 그림을 보여줘

친구한테 "그 카페 알지? 거기 분위기로" 하면 못 알아듣지만, 사진을 보여주면 단번에 통하지. 클로드 코드도 글보다 그림을 보면 훨씬 정확하게 만들어.

비유 클로드 코드에서 주의
참고 사진 보여주기 이미지 드래그/붙여넣기 화질 좋은 이미지로
"여기 이상해"라며 사진 가리키기 스크린샷으로 위치 지정 모호한 말 대신 그림
손그림 레이아웃 스케치 ASCII 목업으로 구조 먼저 코드 전에 구조 확인
통역사 Figma MCP로 디자인->코드 도구 설정은 공식 문서

따라 하기

# 팁 28: 이미지 주입 — 드래그 앤 드롭 또는 Ctrl+V
# 참고 디자인 이미지를 붙여넣기

# 팁 29: UI 스크린샷 활용
# 잘못된 예: "버튼 위치가 이상해" (어디인지 모름)
# 올바른 예: 스크린샷 후 "이 부분을 수정해줘"

# 팁 30: ASCII 코드로 디자인 목업
"로그인 페이지의 레이아웃을 ASCII로 먼저 보여줘"
# 텍스트로 빠르게 구조 확인 후 코드 작성

# 팁 31: Figma MCP 연동
# Figma 디자인을 MCP로 연결 -> 디자인을 코드로 변환

여기서 잠깐, 새 말 한 줄. ASCII 목업은 글자와 기호만으로 화면 배치를 대충 그린 거야. 종이에 네모 칸으로 그린 화면 스케치를 키보드 글자로 옮긴 셈이지.

이럴 때 이렇게 "버튼이 이상하다"만으론 안 통한다 → 스크린샷 찍어 "이 부분". 디자인이 복잡하다 → 먼저 ASCII 목업으로 큰 틀부터 합의.

한 걸음 더 ▸ Figma MCP 같은 외부 연결

Figma MCP는 디자인 도구 Figma의 화면을 클로드 코드로 끌어오는 연결이야. 이런 외부 연결(MCP)은 뒤쪽 묶음에서 따로 다뤄. 지금은 "그림도 가져올 수 있다" 정도만 기억하면 돼.

다음 장 예고: 코드가 만들어질 때마다 자동으로 검사 돌리는 법. 지금 몰라도 됨.

7. 작업 및 테스트 자동화 (팁 32~37)

이 장에서 딱 3가지만. 1) 훅으로 작업 끝날 때마다 검사를 자동 실행한다 2) 테스트 조건을 자연어로 말하면 된다 3) E2E와 엣지 케이스까지 부탁하면 품질이 오른다

학습 목표 이 장을 마치면 훅이 무엇을 하는지 설명한다. 자연어 테스트 요청법을 따라 한다. E2E와 엣지 케이스를 구분한다.

검사하는 걸 자꾸 깜빡했죠? 그럼 자동으로 돌게 하자

공장에는 제품이 나올 때마다 자동으로 불량을 걸러내는 검사 라인이 있어. "불량이면 알려줘"라고 미리 설정해둔 거지. 클로드 코드에서 이 자동 검사 설정이 훅(Hook)이야.

비유 클로드 코드에서 주의
공장 자동 검사 라인 훅 — 작업 후 자동 테스트/린트 설정 파일에 등록
검사 기준을 말로 정함 "로그인 실패 시 에러 뜨는지 테스트해줘" 코드 직접 안 짜도 됨
출고 전 종합 점검 QA 자동화 (테스트+린트+빌드) 결과 보고 개선까지
처음부터 끝까지 시운전 E2E 테스트 사용자 흐름 전체

따라 하기

# 팁 32: 클로드 코드 훅 — 작업 완료마다 검사 실행
# 설정 파일(.claude/settings.local.json)에 훅을 등록
# -> 코드 변경 시 자동으로 린트 + 테스트

# 팁 33: 자연어로 테스트 자동화
# 잘못된 예: 테스트 코드를 손으로 직접 작성
# 올바른 예: "로그인 실패 시 에러 메시지가 표시되는지 테스트해줘"

# 팁 34: QA 자동화
"테스트, 린트, 빌드를 실행하고 결과 기반으로 코드를 개선해줘"

# 팁 35: QA 목표 지정
"유닛 테스트 커버리지 80% 이상이 될 때까지 테스트 코드 작성해줘"

# 팁 36: E2E 테스트
"Playwright로 회원가입 -> 로그인 -> 대시보드 접근 E2E 테스트 만들어줘"

# 팁 37: 엣지 케이스 포함 요청
"엣지 케이스도 포함해서 더 상세한 테스트 케이스를 만들어줘"

여기서 잠깐, 새 말 두 줄. E2E 테스트는 사용자가 처음 화면부터 끝까지 실제처럼 눌러보는 통합 시험이야. 엣지 케이스는 "빈칸으로 제출", "엄청 긴 글자" 같은 극단적 상황이야.

이럴 때 이렇게 검사를 자꾸 잊는다 → 훅으로 자동화, 손 안 대도 매번 돌게. "진짜 잘 되나?" 불안하다 → E2E로 처음부터 끝까지 한 번에.

한 걸음 더 ▸ 훅과 안전한 모드의 궁합

훅으로 검사가 자동으로 돌면, 1장의 자동 승인이나 YOLO 모드를 더 안심하고 쓸 수 있어. 자동으로 일하다가도 검사에서 걸리면 알려주니까. 훅 설정 파일의 자세한 형식은 공식 문서를 확인하자. (시간이 지나면 바뀔 수 있어.)

다음 장 예고: 모델 고르기와 토큰 아끼기. 지금 몰라도 됨.

8. 토큰 및 요금 관리 (팁 38~43)

이 장에서 딱 3가지만. 1) 작업 난이도에 맞는 모델을 골라라 2) 5시간 블록을 알고 쓰면 한도에 덜 부딪힌다 3) ccusage로 사용량을 눈으로 확인해라

학습 목표 이 장을 마치면 모델을 작업에 맞게 구분한다. 5시간 블록이 무엇인지 설명한다. ccusage가 무엇을 하는지 설명한다.

비싼 모델로 사소한 일 했다가 토큰 날린 적 있죠?

급한 회의엔 택시를 타지만, 매일 출근까지 택시면 돈이 너무 많이 들지. 출근은 버스가 경제적이야. 클로드 코드의 모델도 마찬가지야. 어려운 일엔 강한(대신 느리고 비싼) 모델, 쉬운 일엔 가벼운 모델.

먼저 약속 하나. 아래 나오는 요금이나 한도 숫자는 원서/노트 기준 예시야. 요금제와 한도는 자주 바뀌니, 정확한 최신 값은 공식 문서에서 확인하자.

비유 클로드 코드에서 주의
택시 (빠르고 비쌈) 강한 모델 — 어려운 디버깅/설계 느리고 토큰 많이 씀
버스 (싸고 충분) 가벼운 모델 — 일상 코드 대부분 일엔 이걸로 충분
데이터 무제한 요금제 상위 플랜 업그레이드 한도에 자주 막히면 고려
교통카드 잔액 확인 ccusage로 사용량 보기 외부 도구, 공식 저장소 확인

따라 하기

# 팁 38: 상위 플랜 고려
# 토큰 한계에 자주 부딪히면 더 높은 요금제 업그레이드 고려
# (요금/한도 수치는 시점마다 다름 -> 공식 문서 확인)

# 팁 39: 작업에 어울리는 모델 사용
# 잘못된 예: 간단한 코드에도 항상 가장 강한 모델
# 올바른 예: 어려운 버그/설계 = 강한 모델, 일상 코드 = 가벼운 모델

# 팁 40: 강한 모델을 무조건 선호하지 않기
# 강하지만 느림 -> 가능하면 가벼운 모델

# 팁 41: 5시간 블록 전략적 운영
# 처음 요청 시점부터 5시간 단위로 토큰 한도가 묶인다
# -> 본격 작업할 시간대에 첫 요청을 시작

# 팁 42: Thinking Token 활용
# Think -> Think Hard -> Think Harder -> Ultrathink
# 뒤로 갈수록 더 깊이 생각하게 함 (대신 토큰을 더 씀)

# 팁 43: ccusage 로 토큰 모니터링
# ccusage 를 설치하면 사용량을 실시간으로 볼 수 있다

여기서 잠깐, 새 말 두 줄. 토큰은 클로드가 글을 읽고 쓸 때 세는 글자 단위야. 통신 요금의 데이터양 같은 거지. Thinking Token은 "더 깊이 생각해"라고 유도하는 키워드야. Think부터 Ultrathink까지 갈수록 더 오래 고민해.

이럴 때 이렇게 사소한 스타일 수정이다 → 가벼운 모델로 빠르게. 한도에 자꾸 막힌다 → ccusage로 사용 패턴부터 확인, 그다음 플랜 고민.

한 걸음 더 ▸ 모델 이름과 요금은 박제하지 말기

이 책은 빠르게 변하는 도구를 다뤄. 모델 이름, 요금, 한도 수치는 시간이 지나면 달라져. 그러니 "이 모델이 얼마"라고 외우기보다, "작업 난이도에 맞춰 고른다"는 원칙만 기억해. 구체 숫자가 필요하면 그때그때 공식 문서를 봐. (ccusage 같은 외부 도구도 공식 저장소 확인.)

다음 장 예고: 클로드의 "기억 책상" 정리하는 법. 지금 몰라도 됨.

9. 콘텍스트 관리 (팁 44~47)

이 장에서 딱 3가지만. 1) 일 시키기 전에 관련 정보를 먼저 깔아줘라 2) /clear로 비우고 /compact로 압축해라 3) 잘못 가면 Esc로 즉시 멈춰라

학습 목표 이 장을 마치면 콘텍스트가 무엇인지 설명한다. /clear와 /compact를 구분한다. Esc로 작업을 멈추는 법을 따라 한다.

책상에 서류가 쌓여 헷갈린 적 있죠? 콘텍스트도 똑같아

책상 위에 지금 필요한 서류만 있으면 일이 잘 되지만, 지난 작업 서류까지 잔뜩 쌓이면 헷갈리지. 클로드의 콘텍스트가 그 책상이야. 지금 기억하고 있는 정보 범위라고 보면 돼.

비유 클로드 코드에서 주의
필요한 서류만 올려두기 작업 전 관련 파일 먼저 주입 @로 파일 지정
책상 싹 비우기 /clear — 콘텍스트 리셋 완전히 다른 작업으로 갈 때
서류 핵심만 요약해 쌓기 /compact — 콘텍스트 압축 자리 부족할 때
잘못 올라온 서류 즉시 치우기 Esc — 작업 중단 "잘못됐다"고 알려주기

따라 하기

# 팁 44: 콘텍스트 주입
# 잘못된 예: "회원가입 수정해줘" (맥락 없음)
# 올바른 예: "회원가입 관련 파일(@src/auth)을 먼저 분석하고,
#            이메일 검증 로직을 수정해줘"

# 팁 45: /clear — 대화 콘텍스트 리셋
/clear
# 완전히 다른 작업으로 넘어갈 때

# 팁 46: /compact — 콘텍스트 압축
/compact
# 자리가 부족할 때 자동 압축을 기다리기보다 직접 실행

# 팁 47: Esc — 잘못된 작업 즉시 취소
# 엉뚱한 방향으로 가면 Esc 로 중단
# -> "방금 건 잘못됐어" 라고 알려줘야 콘텍스트 오염 방지

여기서 잠깐, 새 말 한 줄. 콘텍스트 오염은 잘못된 정보가 책상에 남아 그다음 일까지 망치는 현상이야. 그래서 잘못 갔을 땐 Esc로 멈추고 "그건 틀렸어"라고 분명히 말해줘야 해.

이럴 때 이렇게 인증 작업 끝내고 결제로 넘어간다 → /clear로 책상 싹 비우고 새 출발. "콘텍스트 부족" 경고가 뜬다 → /compact로 핵심만 압축.

한 걸음 더 ▸ 주입부터 먼저인 이유

5장에서 본 @파일 참조를 작업 전에 먼저 깔아주면 결과가 훨씬 정확해. "수정해줘"보다 "이 파일들 보고 → 이 부분 수정해줘"가 늘 낫다는 거지. 앞 장 내용을 여기서 다시 쓰는 셈이야.

다음 장 예고: 외부 서비스를 클로드에 꽂는 MCP 이야기. 지금 몰라도 됨.

10. MCP (팁 48~52)

이 장에서 딱 3가지만. 1) MCP는 클로드 코드에 외부 서비스를 꽂는 규격이다 2) context7로 최신 공식 문서를 끌어온다 3) 필요한 MCP만 골라 설치한다

학습 목표 이 장을 마치면 MCP가 무엇인지 설명한다. context7이 무엇을 하는지 설명한다. 필요한 MCP를 고르는 기준을 구분한다.

기본 기능만으론 부족했죠? 그럼 앱을 깔자

새 스마트폰은 기본 기능만으로도 쓸 수 있지만, 지도 앱, 은행 앱, 결제 앱을 깔면 할 수 있는 일이 확 늘어나. 클로드 코드에 외부 서비스를 깔아주는 게 MCP야.

비유 (스마트폰 앱) 클로드 코드에서 주의
지도 앱 context7 — 최신 공식 문서 검색 최신 정보 확인용
은행/DB 앱 Supabase MCP — 데이터베이스/인증 연동 외부 서비스 계정 필요
메모 정리 보조 Sequential Thinking MCP — 체계적 사고 유도 복잡한 문제에
결제 앱 TossPayments MCP — 결제 연동 외부 서비스, 공식 확인

따라 하기

# 팁 48: MCP 활용 — 클로드 코드의 기능 확장
# 공식 문서 검색, DB 조회, 결제 연동 등

# 팁 49: context7 MCP — 최신 공식 문서 검색
# 예: "React 19의 use() 훅 사용법" 같은 최신 정보 조회

# 팁 50: Supabase MCP
# 데이터베이스 연동, 인증, 스토리지 등을 직접 사용

# 팁 51: Sequential Thinking MCP
# 클로드가 단계를 나눠 더 체계적으로 사고하도록 유도

# 팁 52: TossPayments MCP
# 결제 연동을 MCP 로 간편하게 처리
# (원서 기준: 대한민국 PG사 중 최초의 MCP)

여기서 잠깐, 새 말 한 줄. MCP는 Model Context Protocol의 줄임말로, 외부 서비스를 클로드 코드에 꽂는 표준 규격이야. 콘센트 규격이 같으면 어떤 기기든 꽂히는 것과 비슷해.

이럴 때 이렇게 라이브러리 최신 사용법이 헷갈린다 → context7로 공식 문서 끌어오기. DB를 자주 다룬다 → Supabase 같은 MCP로 직접 연동.

한 걸음 더 ▸ MCP는 골라서 깔기

앱을 전부 깔면 폰이 무거워지듯, MCP도 필요 없는 걸 다 깔면 복잡해져. 지금 프로젝트에 진짜 필요한 것만 골라 깔자. MCP 종류와 설정 방법은 자주 바뀌니, 각 도구의 공식 문서를 확인해. 6장에서 본 Figma MCP도 이런 MCP의 한 예였어.

다음 장 예고: 디자인 컴포넌트와 참고 사이트 활용법. 지금 몰라도 됨.

11. 디자인 및 구성요소 (팁 53~55)

이 장에서 딱 3가지만. 1) 코드 전에 컴포넌트 데모 페이지부터 만들어라 2) 참고 사이트 URL을 직접 줘라 3) Playwright로 사이트 테마를 JSON으로 정리하라

학습 목표 이 장을 마치면 컴포넌트 데모 페이지가 무엇인지 설명한다. URL을 참고로 주는 법을 따라 한다. Playwright 크롤링이 무엇을 하는지 설명한다.

옷 만들 때 본부터 뜨죠? 디자인도 패턴 먼저

옷을 바로 재단하지 않고 패턴(본)부터 뜨면 실수가 줄어. 화면 만들기도 똑같아. 버튼, 카드, 폼 같은 부품을 한 페이지에 모아둔 컴포넌트 데모 페이지가 그 본이야.

비유 클로드 코드에서 주의
옷 패턴(본) 뜨기 컴포넌트 데모 페이지 먼저 부품을 한 곳에 모음
패션 잡지 참고 참고 사이트 URL 주기 그대로 베끼진 말기
잡지 스타일 분석 Playwright로 테마 추출 JSON으로 정리

따라 하기

# 팁 53: 디자인 컴포넌트 데모 페이지
"디자인 컴포넌트 데모 페이지를 먼저 만들어줘 — 버튼, 카드, 폼 등"

# 팁 54: 웹사이트 URL 입력
"https://example.com 의 레이아웃을 참고해서 만들어줘"

# 팁 55: Playwright 로 웹사이트 크롤링
"이 사이트를 Playwright로 크롤링해서 테마를 JSON으로 정리해줘"
# 색상, 폰트, 간격 등을 구조화된 데이터로 추출

여기서 잠깐, 새 말 두 줄. 컴포넌트는 버튼, 카드처럼 화면을 이루는 재사용 부품이야. Playwright는 사람 대신 웹페이지를 자동으로 열고 살펴보는 도구야. (7장의 E2E 테스트에서도 등장했지.)

이럴 때 이렇게 화면 스타일을 통일하고 싶다 → 컴포넌트 데모 페이지부터. "저 사이트 같은 느낌" → URL 주고, 테마를 JSON으로 뽑아 재활용.

한 걸음 더 ▸ 데모 페이지가 주는 이득

부품을 미리 한 곳에 모아두면, 나중에 화면마다 같은 버튼을 또 만들 필요가 없어. 색이나 모양을 바꿀 때도 한 곳만 고치면 돼서 편해.

다음 장 예고: 큰 작업을 잘게 나눠 관리하는 흐름 만들기. 지금 몰라도 됨.

12. 작업 흐름 관리 (팁 56~69)

이 장에서 딱 3가지만. 1) 역할(페르소나)과 설계도(PRD)를 먼저 정해라 2) 큰 일은 잘게 나누고 체크박스로 진행을 봐라 3) 잘못되면 되돌리고(Esc 2번), 결과 포맷과 문서화를 챙겨라

학습 목표 이 장을 마치면 페르소나와 PRD를 구분한다. 체크박스로 진행을 관리하는 법을 따라 한다. 작업 분할이 왜 좋은지 설명한다.

한 번에 다 시켰다가 엉킨 적 있죠? 건물처럼 공정을 나누자

집을 지을 때 설계도 없이 벽부터 쌓진 않잖아. 설계도 그리고, 공정표 짜고, 층층이 올리고, 검수하지. 클로드 코드 작업도 이렇게 흐름을 잡으면 훨씬 안정적이야.

비유 (건축) 클로드 코드에서 주의
전문가 섭외 페르소나 부여 역할을 또렷이
설계도 PRD 먼저 작성 요구사항 정리
공정표 마크다운 체크박스 진행 한눈에
층별 공사 작업 분할 한 번에 다 X
시공->검수->보완 피드백 루프 반복으로 품질

따라 하기

# 팁 56: 페르소나 부여
"너는 시니어 백엔드 개발자야. FastAPI로 인증 시스템을 설계해줘"

# 팁 57: PRD 먼저 작성
"프로젝트의 PRD를 먼저 작성하고, 적절한 CLAUDE.md를 만들어줘"

# 팁 58: 워크트리 활용
# 메인 브랜치에 영향 없이 독립된 브랜치에서 실험

# 팁 59: 피드백 루프 (계획 -> 작업 -> 확인 -> 수정)
# CLAUDE.md 에 이 반복 흐름을 규칙으로 기록

# 팁 60~61: 여러 스텝에 걸쳐 작업 / Esc 두 번으로 되돌리기

# 팁 62: 마크다운 체크박스로 진행 모니터링
# - [x] DB 스키마 설계
# - [ ] API 엔드포인트 구현
# - [ ] 프론트엔드 연동

# 팁 63: 작업 사항 확인 — 과도한 신뢰 방지
# 다 됐다고 해도 직접 한 번 확인

# 팁 64: 작업 되돌리기
"방금 작업이 마음에 안 드니 이전 상태로 되돌려줘"

# 팁 65: 작업 분할
"이 작업을 작은 단위로 분할해줘"

# 팁 66: 작업하지 말라고 하기 (계획만)
"코드는 작성하지 말고, 계획만 먼저 세워줘"

# 팁 67: 결과물 포맷 지정
"결과를 JSON 형식으로 출력해줘"

# 팁 68: 작업 파일로 저장
# 한 번에 못 끝내면 진행 상황을 마크다운 파일에 기록

# 팁 69: 문서화 자주하기
"README.md와 마이그레이션 가이드를 정리해줘"

여기서 잠깐, 새 말 세 줄. 페르소나는 클로드에게 "너는 ~전문가야"라고 역할을 입히는 거야. 배우에게 배역을 주는 것과 같아. PRD는 제품 요구사항 문서로, 무엇을 만들지 적은 설계도야. 워크트리는 메인을 안 건드리고 따로 떼어 실험하는 작업 공간이야. (Git의 기능이야.)

이럴 때 이렇게 큰 기능을 한 번에 시켰더니 엉켰다 → "작은 단위로 분할해줘". 진행이 헷갈린다 → 체크박스로 끝난 것/남은 것 한눈에.

한 걸음 더 ▸ "계획만 세워줘"가 특히 빛날 때

YOLO 모드처럼 알아서 다 하는 상황에서는, 먼저 "코드는 짜지 말고 계획만"이라고 막아두면 폭주를 예방해. 1장에서 본 플래닝 모드와 짝을 이루는 습관이야. 되돌리기(Esc 두 번)도 9장에서 본 Esc의 연속 동작이야.

다음 장 예고: GitHub와 이어서 커밋/PR을 자동화하는 법. 지금 몰라도 됨.

13. 깃허브 연동 (팁 70~76)

이 장에서 딱 3가지만. 1) GitHub App과 gh CLI로 연동한다 2) 이슈 번호를 주고 작업을 시킨다 3) 커밋 메시지와 PR을 자동으로 맡긴다

학습 목표 이 장을 마치면 GitHub App 설치법을 따라 한다. 이슈 번호로 작업 지시하는 법을 따라 한다. PR과 커밋 메시지 자동화를 구분한다.

회의록, 보고서, 할일… 다 직접 정리했죠? 비서한테 맡기자

비서가 회의록(커밋 메시지)을 정리하고, 보고서(PR)를 올리고, 할일(이슈)을 관리해주면 편하지. 클로드 코드가 그 Git 전담 비서 역할을 해줄 수 있어.

비유 (비서) 클로드 코드에서 주의
회의록 정리 커밋 메시지 자동 작성 한 번 읽어보기
보고서 제출 PR 자동 생성 내용 확인 후
할일 목록 관리 이슈 번호로 작업 지시 번호 정확히
비서 채용 절차 GitHub App / gh CLI 설치 한 번만 설정

따라 하기

# 팁 70: GitHub App 설치
/install-github-app
# PR 리뷰, 이슈 해결에 클로드 활용

# 팁 71: GitHub CLI 설치
# gh CLI 설치 -> 현재 리포지터리 정보를 자동 연동

# 팁 72: 이슈 활용
"GitHub 이슈 #15를 해결해줘"

# 팁 73: 프로젝트 세팅 커밋
# 커스텀 커맨드, 클로드 코드 세팅을 커밋 -> 팀과 공유

# 팁 74: PR 생성 요청
"풀 리퀘스트를 만들어줘"
# 지금까지의 커밋을 기반으로 PR 자동 생성

# 팁 75: 커밋 메시지 부탁하기
"커밋 메시지를 작성해줘"

# 팁 76: 자주 커밋하기
# "작업하면서 자주 커밋해줘" 라고 요청
# -> 특정 시점으로 쉽게 되돌리기 가능

여기서 잠깐, 새 말 두 줄. 이슈는 "여기 버그 있음", "이 기능 추가하자" 같은 할일을 번호로 적어두는 GitHub 메모야. PR(풀 리퀘스트)은 "내가 이만큼 고쳤으니 합쳐주세요" 하고 올리는 변경 제안서야.

이럴 때 이렇게 처리할 버그가 GitHub에 적혀 있다 → "이슈 #15 해결해줘". 커밋 메시지 쓰기 귀찮다 → "커밋 메시지를 작성해줘".

한 걸음 더 ▸ 자주 커밋이 안전망인 이유

자주 커밋해두면, 12장에서 본 "되돌리기"가 훨씬 쉬워져. 저장 지점이 촘촘할수록 원하는 시점으로 정확히 돌아갈 수 있거든. 세팅 파일을 커밋해 팀과 공유하면 모두 같은 규칙으로 일할 수 있어.

다음 장 예고: 반복을 줄이는 생산성 전략 모음. 지금 몰라도 됨.

14. 생산성 전략 (팁 77~86)

이 장에서 딱 3가지만. 1) 안전한 명령은 "항상 허용"으로 시간 아껴라 2) 자주 쓰는 프롬프트는 커스텀 커맨드로 저장해라 3) 작업은 레이어로 나누고, 예제를 주면 품질이 오른다

학습 목표 이 장을 마치면 "항상 허용"의 쓰임을 설명한다. 커스텀 커맨드와 아규먼트를 구분한다. 레이어 분리가 왜 좋은지 설명한다.

매번 똑같은 걸 허락하고, 똑같은 걸 입력했죠? 줄이자

요리를 빨리 하려면 자주 쓰는 양념은 손 닿는 곳에 두고(항상 허용), 즐겨 만드는 레시피는 적어두고(커스텀 커맨드), 메인·사이드·디저트를 나눠서 준비하지(레이어 분리). 클로드 코드 작업도 똑같이 정리하면 빨라져.

비유 (요리) 클로드 코드에서 주의
양념 손 닿는 곳에 안전한 명령 "항상 허용" 정말 안전한 것만
레시피 저장 커스텀 커맨드 등록 자주 쓰는 것만
레시피에 재료 칸 커맨드 아규먼트 값만 바꿔 재사용
코스 나눠 준비 레이어 분리 (DB->API->프론트) 한 번에 다 X
견본 요리 보여주기 예제 제공 비슷한 스타일 유도

따라 하기

# 팁 77: 항상 허용 등록
# 안전한 커맨드(ls, git status 등)는 "항상 허용" 선택

# 팁 78: 커스텀 커맨드 등록
# /my-deploy, /my-test 등 자주 쓰는 프롬프트를 등록

# 팁 79: 커스텀 커맨드에 아규먼트 사용
# /fix-bug issue-20   <- "issue-20" 이 값으로 전달됨

# 팁 80: 적절한 스코프 사용
# 사용자 스코프 / 프로젝트 스코프 / 로컬 스코프 구분

# 팁 81: 프롬프트 큐에 적재하기
# 지금 작업이 도는 동안 다음 프롬프트를 미리 입력해 둠

# 팁 82: 레이어별로 작업시키기
# 잘못된 예: "프론트+백엔드+DB 한 번에 만들어줘"
# 올바른 예: "먼저 DB 스키마만" -> "API만" -> "프론트만"

# 팁 83: 예제 제공
# 잘못된 예: "카드 컴포넌트 만들어줘"
# 올바른 예: "이 예제(@components/Card.tsx)를 참고해서 비슷한 스타일로"

# 팁 84: 관련 코드 찾아달라고 하기
"인증 관련 파일과 관련 함수들을 찾아줘"

# 팁 85: DB 조회 권한 주기 (MCP)
# PostgreSQL/MySQL MCP 로 DB 조회 -> 효율적 디버깅

# 팁 86: 클로드 코드끼리 경쟁시키기
# 터미널 2개: 하나는 코드 작성, 하나는 코드 검증

여기서 잠깐, 새 말 두 줄. 커스텀 커맨드는 자주 쓰는 프롬프트를 /이름으로 저장해 버튼처럼 부르는 거야. 아규먼트는 그 커맨드에 끼워 넣는 값이야. 레시피의 빈 재료 칸에 그날 재료를 넣는 셈이지.

이럴 때 이렇게 같은 프롬프트를 매일 친다 → 커스텀 커맨드로 저장. 값만 바뀐다(이슈 번호 등) → 아규먼트로 받게 만들기.

한 걸음 더 ▸ 스코프가 뭐야

스코프는 "이 설정이 어디까지 적용되는가"의 범위야. 나만 쓰는지(사용자), 이 프로젝트 전체인지(프로젝트), 내 로컬에서만인지(로컬)로 나뉘어. DB 조회 권한 주기(팁 85)는 10장에서 본 MCP를 쓰는 또 다른 예야.

다음 장 예고: 클로드 코드 생태계의 외부 도구들. 지금 몰라도 됨.

15. 외부 도구 활용 (팁 87~93)

이 장에서 딱 3가지만. 1) 데스크톱 앱·IDE 익스텐션으로 환경을 넓혀라 2) Super Claude·Claude Squad·Claudia 같은 외부 도구를 곁들여라 3) 다른 AI CLI를 병용해 비용을 아껴라

학습 목표 이 장을 마치면 외부 도구가 무엇을 보완하는지 설명한다. Super Claude와 Claudia를 구분한다. IDE 익스텐션의 쓸모를 설명한다.

CLI만으로 답답했죠? 주변기기를 붙이자

메인 컴퓨터(클로드 코드)에 보조 모니터, 키보드 매크로, 클라우드 저장소를 붙이면 훨씬 편하잖아. 외부 도구들이 바로 그 주변기기야. 각자 특화된 기능이 있어서, 곁들여 쓰면 CLI의 한계를 넘어설 수 있어.

먼저 약속 하나. 아래 외부 도구들은 모두 서드파티(다른 곳에서 만든 도구)야. 여기 소개는 원서 작성 시점 기준이고, 설치 방법과 옵션은 각 도구의 공식 저장소에서 확인해. (자주 바뀜.)

비유 (주변기기) 도구 (공식 명칭) 한 줄 쓸모
보조 모니터 클로드 데스크톱 (GUI 앱) 긴 작업에서 문맥 유지
검증된 매크로 세트 Super Claude 다듬어진 커스텀 커맨드 모음
작업 공간 정리기 Claude Squad 워크트리를 더 쉽게
즐겨찾기 저장소 Claudia 작업 패턴을 에이전트로 저장
메모판 스크래치패드 작업 과정을 눈에 보이게
보조 일꾼(다른 회사) Gemini CLI 등 토큰/콘텍스트 분담
에디터 플러그인 IDE 익스텐션 에디터 선택 영역 바로 작업

따라 하기

# 팁 87: 클로드 데스크톱 — 긴 작업에서 문맥 유지
# CLI + 데스크톱 앱 함께 사용

# 팁 88: Super Claude — 다듬어진 커스텀 커맨드 모음
# 무료 오픈소스, 설치 후 사용 (설치법은 공식 저장소 확인)

# 팁 89: Claude Squad — 워크트리를 더 편하게
# 워크트리 사용이 어려우면 Squad 로 간소화

# 팁 90: Claudia — 에이전트를 저장/재사용
# 프레임워크 부트스트래핑 같은 반복 작업을 에이전트화

# 팁 91: 스크래치패드 — 작업 과정을 시각적으로
"스크래치패드를 사용해서 작업해줘"

# 팁 92: Gemini CLI 등 다른 에이전트 병용
# 클로드 코드 + 다른 CLI -> 토큰/콘텍스트 절약

# 팁 93: IDE 익스텐션 설치
# 에디터에 클로드 코드 익스텐션 설치
# -> 현재 프로젝트의 선택 영역을 바로 작업

여기서 잠깐, 새 말 두 줄. 서드파티는 Anthropic이 아닌 다른 사람/팀이 만든 도구라는 뜻이야. IDE 익스텐션은 코드 에디터에 끼우는 추가 기능(플러그인)이야.

이럴 때 이렇게 워크트리(12장)가 어렵게 느껴진다 → Claude Squad로 더 쉽게. 같은 작업 패턴을 자꾸 반복한다 → Claudia로 에이전트화해 저장.

한 걸음 더 ▸ 외부 도구를 쓸 때 주의

외부 도구는 만든 주체가 달라서 업데이트 시점도 제각각이야. 그래서 이름과 큰 쓸모만 기억하고, 설치·옵션·버전은 항상 각 공식 저장소에서 확인해. 이 책이 다루는 "빠르게 변하는 정보"의 대표 사례라고 보면 돼.

다음 장 예고: 개발이 막막한 사람을 위한 마음가짐 팁. 지금 몰라도 됨.

16. 개발을 어려워하는 당신에게 (팁 94~99)

이 장에서 딱 3가지만. 1) 리팩터링·여러 옵션·분석추천을 적극 부탁해라 2) 코드를 직접 쓰기보다 방향을 정하는 매니저가 돼라 3) 포기하지 말고 경험을 쌓아라

학습 목표 이 장을 마치면 리팩터링 요청법을 따라 한다. 여러 옵션을 요구하는 법을 따라 한다. 매니저 마인드셋이 무엇인지 설명한다.

코드를 다 알아야만 하나? 아니, 좋은 내비만 있으면 돼

초보 운전자도 좋은 내비게이션이 있으면 목적지에 도착해. 클로드 코드가 그 내비야. 운전 기술이 부족해도, 어디로 갈지 정하고 길을 검토하는 것만 잘하면 충분해.

비유 (운전) 클로드 코드에서 주의
더 빠른 길 안내 리팩터링 요청 자주 정리
경로 3개 보여주기 여러 옵션 요구 비교 후 선택
길 추천받기 분석 후 추천 요청 근거 함께 듣기
운전보다 목적지 정하기 매니저 역할로 전환 방향+검토에 집중

따라 하기

# 팁 94: 자주 리팩터링 요청
"이 코드를 더 효율적으로 리팩터링해줘"
# 클로드 코드는 리팩터링을 매우 잘함

# 팁 95: 여러 옵션 요구
"카드 디자인을 개선할 수 있는 5가지 방법을 보여줘"

# 팁 96: 분석시키고 추천받기
"A 방식과 B 방식 중 어떤 것이 나은지 분석해서 추천해줘"

# 팁 97: 매니저 역할로 전환
# 코드를 직접 쓰기보다, 방향을 제시하고 검토하는 역할

# 팁 98: 코드팩토리 유튜브 구독
# 꿀팁이 계속 업데이트됨

# 팁 99: 포기하지 말기!
# AI와 함께 코딩하는 것도 경험이 쌓이면 큰 효율이 난다

여기서 잠깐, 새 말 한 줄. 리팩터링은 동작은 그대로 두고 코드를 더 깔끔하게 정리하는 일이야. 방은 그대로지만 물건을 정돈하는 것과 같아.

이럴 때 이렇게 어느 방법이 나은지 모르겠다 → "분석해서 추천해줘"로 근거까지. 코드가 점점 지저분해진다 → "리팩터링해줘"로 주기적 정리.

한 걸음 더 ▸ 매니저 마인드셋

매니저는 직접 못질을 하기보다, 무엇을 어디에 지을지 정하고 결과를 검수해. 클로드 코드와 일할 때도 이 관점으로 바꾸면, 개발 경험이 적어도 좋은 결과를 낼 수 있어. 이 부록 전체가 결국 그 매니저 역할을 돕는 도구 모음이었던 거야.

이 부록은 여기까지야. 99가지를 다 외우려 하지 말고, 오늘 하나만 골라 써 보자. 그 하나가 손에 익으면, 자연스럽게 다음 하나로 넘어가게 돼.

정리 표 (한눈에 다시 보기)

실행 모드 4가지

모드 확인 정도 언제 좋나
일반 매번 확인 민감한 작업, 배우는 중
자동 승인 안전한 것만 자동 익숙한 반복 작업
YOLO 전부 자동 안전한 반복(테스트/린트)
플래닝 계획 먼저 복잡한 새 기능

콘텍스트 관리 3종

명령/키 하는 일 언제
/clear 책상 싹 비우기 완전히 다른 작업으로
/compact 핵심만 압축 자리 부족할 때
Esc 즉시 멈춤 (두 번은 되돌리기) 잘못된 방향일 때

자주 쓰는 단축/명령

명령 하는 일
/init 프로젝트 분석 후 CLAUDE.md 생성
/model 현재 모델 확인 (낭비 방지)
/release 새 기능(릴리즈 노트) 확인
-p 헤드리스 — 대화 없이 한 번 실행
@파일 파일 콕 집어 참조
-r / -c 이전 대화 / 직전 대화 이어가기
# CLAUDE.md에 즉석 규칙 추가

위 표의 모델 이름·요금·도구 버전은 모두 원서/노트 기준 예시야. 빠르게 변하는 정보이니, 최신 값은 공식 문서와 각 도구 공식 저장소에서 확인하자.

스스로 점검 (연습문제)

문제 1. 모델 고르기

아래 일에 무거운 모델과 가벼운 모델 중 무엇이 어울릴까? (난이도 기준으로만 생각) (a) 복잡한 인증 버그 잡기 (b) 간단한 CRUD 만들기 (c) 전체 구조 설계 (d) CSS 살짝 수정

정답 보기 (a) 무거운 모델 — 깊은 추론이 필요 (b) 가벼운 모델 — 패턴화된 코드라 충분 (c) 무거운 모델 — 추상적 설계가 필요 (d) 가벼운 모델 — 단순 수정이라 빠른 게 이득 (구체 모델명은 시점마다 다르니 공식 문서 확인. 여기선 "난이도에 맞춰 고른다" 원칙만 익히면 돼.)

문제 2. 작업 전환 시 콘텍스트 정리 순서

인증 작업을 3시간 하고, 이제 결제로 넘어가려 해. 어떤 순서가 좋을까?

정답 보기 1. `/clear`로 인증 콘텍스트를 비운다 2. 결제 관련 파일을 `@`로 새로 주입한다 3. "결제 코드를 먼저 분석해줘"로 맥락을 깐다 4. 자리 부족하면 `/compact`로 압축한다 5. 잘못 가면 Esc로 멈추고 "그건 틀렸어"라고 알려준다

문제 3. 할일 앱 만들기 흐름

새 Todo 앱을 처음부터 만든다면, 어떤 팁들을 순서대로 쓸 수 있을까?

정답 예시 1. 팁 19 `/init` — 프로젝트 초기화, CLAUDE.md 생성 2. 팁 57 PRD — 요구사항 문서 먼저 3. 팁 02 플래닝 모드 — 전체 계획부터 4. 팁 82 레이어 분리 — DB -> API -> 프론트 5. 팁 56 페르소나 — "시니어 풀스택"으로 역할 부여 6. 팁 53 컴포넌트 데모 — UI 부품 먼저 7. 팁 33 자연어 테스트 — "추가/삭제 동작 테스트해줘" 8. 팁 50 Supabase MCP — DB 연동 9. 팁 76 자주 커밋 — 기능마다 저장 10. 팁 74 PR 생성 — 완성 후 제안서 올리기 11. 팁 94 리팩터링 — 코드 정리 12. 팁 69 문서화 — README 정리
난이도
에피소드
질문
카드를 로딩 중...
답변

클릭하거나 Space를 눌러 뒤집기

0 / 0
학습 진도 0%
← → 이동   Space 뒤집기   R 셔플